This introduces a new Authorizer, which is hookable per KlothoMain.
The default one just calls auth.Authorize(), but KlothoMains can provide
an alternative, including one that adds flags.

resolves #164

Before this, the server's /logintoken API would return instantly, with
either the token from auth0 or 404 if it hadn't been set yet from the
auth0.com callback. So, we needed a callback not just for intermittent
errors, but for the happy path functionality. Now, the /logintoken call
hangs until it gets that token (or times out), so the happy path doesn't
need a retry. We could still need a retry for intermittent failurs, but
that's a more general problem that we should resolve across all http
calls, not just for auth.

I'm also moving the Login error handler to a callback, just as an
organizational tool. We want to send the analytics for any error
manually (since the client hasn't been set up yet), but the Login method
shouldn't have to know about that intricacy. klothomain.go does, so
that's where we should put that logic

I'm doing it as a base (instead of just hostname) so that people can
specify http and port (especially for localhost testing).

In some cases, were creating the deferred close after the method would
have already returned. Also, we were dropping some errors on the ground;
this will now handle them.

- split analytics/client.go:NewClient up, such that its email stuff is
  in a new method, AttachAuthorizations().
- rm most of analytics/user.go, and replace it with a tiny method
  GetOrCreateAnalyticsFile(). This just upserts the
  ~/.klotho/analytics.json file. All of the logic around retrieving the
  user and validating emails and all that is just gone.
- auth/auth.go:
  - Authorize() now returns its claims. We pass these to
    AttachAuthorizations(), mentioned above.
  - We download our auth0 PEM (and cache it), and use it to verify the
    auth0 token. Without this, we can't actually get the claims.
- cli/klothomain.go:
  - construct analytics.Client just once, and then later attach the
    email from the claims (this resolves #180)
  - also move the log hooks up, to follow the client
- use RegisteredClaims instead of StandardClaims. Per the [jwt docs][1]:
   > Deprecated: Use RegisteredClaims instead for a forward-compatible way
   > to access registered claims in a struct.

[1]: https://pkg.go.dev/github.com/golang-jwt/jwt/v4#StandardClaims

If the `credentials.json` file isn't there at all, then require a login.
But if it's there but the login doesn't work for whatever reason, just
issue a warning and move on. Meanwhile, in the login path, handle errors
by writing an empty `credentials.json` and then ignoring the error.

resolves #194

Relatedly, add a workaround for #195. It's very easy to hit it with this
new path, so I felt like a quick workaround is in order.

In service of #218